Putting in All the Stops

Scores of compilers produce JavaScript, enabling programmers to use many languages on the Web, reuse existing code, and even use Web IDEs. Unfortunately, most compilers expose the browser’s compromised execution model, so longrunning programs freeze the browser tab, infinite loops crash IDEs, and so on. The few compilers that avoid these problems suffer poor performance and are difficult to engineer. This paper presents Stopify, a source-to-source compiler that extends JavaScript with debugging abstractions and blocking operations, and easily integrates with existing compilers. We apply Stopify to ten programming languages and develop a Web IDE that supports stopping, single-stepping, breakpointing, and long-running computations. For nine languages, Stopify requires no or trivial compiler changes. For eight, our IDE is the first that provides these features. Two of our subject languages have compilers with similar features. Stopify’s performance is competitive with these compilers and it makes them dramatically simpler. Stopify’s abstractions rely on first-class continuations, which it provides by compiling JavaScript to JavaScript. We also identify sub-languages of JavaScript that compilers implicitly use, and exploit these to improve performance. Finally, Stopify needs to repeatedly interrupt and resume program execution. We use a sampling-based technique to estimate program speed that outperforms other systems. 1 Programming On the Web Over the last decade, Web browsers have evolved into a powerful and universally-supported software platform. Traditional desktop programs, such as word processors, spreadsheets, and photo editors now compete with Web-based alternatives. More recently, the Web has started to affect programming technology too. Scores of programming languages compile to run on the Web [25] and there are several Web IDEs in widespread use [5, 9, 15, 39, 47, 48, 57, 68, 76, 80]. This growing audience for Web IDEs, and correspondingly languages that run in the browser, includes professionals and students. Whereas sales of traditional computers are shrinking [2], ChromeBooks now account for 58% of new devices sold to U.S. schools [65]. Unfortunately, JavaScript and the Web platform lack abstractions necessary to build IDEs and serve as a complete compilation target for high-level languages. As a result, we observe compilers for high-level languages that compromise on semantics, and popular Web IDEs that compromise on basic debugging and usability features. Moreover, as we explain in §7, new technologies such as WebAssembly andWeb Workers do not address most of the problems that we address. Indeed, our work may be viewed as presenting additional challenges to the creators of those technologies. Limitations in Web IDEs The key problem facing a Web IDE is that JavaScript has a single-threaded execution environment.1 An IDE that wants to provide a “stop” button to halt runaway computation faces a nontrivial problem, because the callback for that button gets queued for execution behind the running code—which is not going to terminate. Related to this, to make pages responsive, the browser threatens to interrupt computations that run longer than a few seconds. This means long-running computations need to be broken up into short events. In turn, because computations cannot run for very long, JavaScript engines in browsers tend to provide very shallow stacks, which is problematic for functional programs that rely on recursion. These limitations are not at all hypothetical. Codecademy, which claims over 25 million users [38], has a Web IDE for JavaScript and for Python. In response to numerous message board requests, CodeAcademy has a help article that explicitly addresses infinite loops that freeze the browser [78]: they suggest refreshing the page, which loses browser state and recent changes. Other systems, such as CodeSchool, Khan Academy, and Python Tutor [20], address this problem by killing all programs that run for more than a few seconds. These problems also afflict research-driven programming languages, such as Elm [12] and Lively Kernel [47], which crash when given an infinite loop. Appendix A discusses all these systems in more detail. 1 An IDE that runs code on a server has several weaknesses: having to pay for potentially unbounded compute cycles; the security concerns of running untrusted code; users having to trust their computation to a server; running off-line; using the browser’s rich DOM environment; state (e.g., current time) reflecting the server and not the client; and more. This paper focuses on IDEs that run user code in the browser. 1 ar X iv :1 80 2. 02 97 4v 1 [ cs .P L ] 8 F eb 2 01 8 Preliminary Solutions There are a handful of robust programming language implementations for the Web: GopherJS (Go) [19], Pyret [57], Skulpt (Python) [67], Doppio (JVM) [75], GambitJS (Scheme) [70], and Whalesong (Racket) [80]. They use sophisticated compilers and runtime systems to support some subset of long-running computations, shared-memory concurrency, blocking I/O, proper tail calls, debugging, and other features that are difficult to implement in the browser. However, these systems have several shortcomings. First, these systems are difficult to build and maintain because of the complexity of, effectively, implementing expressive control operators for which JavaScript has no native support. For example, GopherJS has had several issues in its implementation of goroutines [11, 13, 14, 17, 43, 71]; Skulpt [67] has had bugs in its debugger [16, 60]; and Pyret has had issues in its Web IDE [24, 29, 30, 32–34, 50–55], and several of these issues remain unresolved. As another example of implementation difficulty, the team that built Pyret previously developed a Web IDE for Scheme [81], but could not reuse the compiler from the Scheme system, because the execution management techniques and the language’s semantics were too tightly coupled. Second, these systems force all programs to pay for all features. For example, Pyret forces all programs to pay the cost of instrumentation for the browser, even if they are running in production or at the command-line; GopherJS forces all programs to pay the cost of goroutines, even if they don’t use concurrency; and Doppio forces all programs to pay the cost of threads, even if they are single-threaded. Third, these compilers have a single back-end—one that is presumably already complex enough—for all browsers, and hence do not maximize performance on any particular browser. Finally, it is very difficult for a compiler author to try a new approach, since small conceptual changes can require the entire compiler and runtime system to change. Furthermore, although these systems use implementation techniques that are interchangeable in principle, in practice they cannot share code to benefit from each others’ performance improvements and bug fixes. What is called for is a clear separation of concerns.